For such a security relevant package such as a vpn software, we should build from source if possible.
I'm not sure why you want to avoid "leaking" the salt, since it can be easily extracted from the binary in the .deb you linked.

This would also allow us to patch out quirks such as relying on /usr

For such a security relevant package such as a vpn software, we should build from source if possible. I'm not sure why you want to avoid "leaking" the salt, since it can be easily extracted from the binary in the .deb you linked.

This would also allow us to patch out quirks such as relying on /usr

Your claims about salts are valid and correct! My earlier statement was based on an incorrect misunderstanding, and I've updated the comment accordingly.

Another way to address quirks is to make changes directly in the NordVPN repository, which was my implicit assumption for the next release.

I could update this to build from scratch, but I don’t see the added security benefit. All other Linux distributions download from repo.nordvpn.com (.deb or .rpm) via their install script. I’ve also noticed that ExpressVPN extracts their .deb. Fortunately, building from source is nearly complete thanks to community efforts. Regardless, I’m not convinced there’s a significant advantage. Lmk your thoughts, thanks!

I could update this to build from scratch, but I don’t see the added security benefit. All other Linux distributions download from repo.nordvpn.com (.deb or .rpm) via their install script. I’ve also noticed that ExpressVPN extracts their .deb. Fortunately, building from source is nearly complete thanks to community efforts. Regardless, I’m not convinced there’s a significant advantage. Lmk your thoughts, thanks!

You are right that most distributions fetch the .deb or .rpm packages from repo.nordvpn.com using the official install script, and that ExpressVPN follows a similar approach in Nixpkgs by extracting the .deb archive.

However, the key issue here is trust and verifiability.

At the moment, there's no reliable way to verify that the binaries provided on repo.nordvpn.com are actually built from the publicly available sources. By using those prebuilt packages, we are implicitly trusting the vendor without any way to independently validate the build integrity.

One of the strengths of Nix is its focus on reproducibility. Building from source allows us (most of the time) to produce reproducible outputs. This enables a verifiable 1-to-1 mapping between the source code and the resulting binaries, which significantly improves the security of the software supply chain.

Fortunately, thanks to recent community efforts, we’re getting close to being able to build the client fully from source.

That’s why I believe it’s worth pushing in that direction.

I could update this to build from scratch, but I don’t see the added security benefit. All other Linux distributions download from repo.nordvpn.com (.deb or .rpm) via their install script. I’ve also noticed that ExpressVPN extracts their .deb. Fortunately, building from source is nearly complete thanks to community efforts. Regardless, I’m not convinced there’s a significant advantage. Lmk your thoughts, thanks!

You are right that most distributions fetch the .deb or .rpm packages from repo.nordvpn.com using the official install script, and that ExpressVPN follows a similar approach in Nixpkgs by extracting the .deb archive.

However, the key issue here is trust and verifiability.

At the moment, there's no reliable way to verify that the binaries provided on repo.nordvpn.com are actually built from the publicly available sources. By using those prebuilt packages, we are implicitly trusting the vendor without any way to independently validate the build integrity.

One of the strengths of Nix is its focus on reproducibility. Building from source allows us (most of the time) to produce reproducible outputs. This enables a verifiable 1-to-1 mapping between the source code and the resulting binaries, which significantly improves the security of the software supply chain.

Fortunately, thanks to recent community efforts, we’re getting close to being able to build the client fully from source.

That’s why I believe it’s worth pushing in that direction.

Gotcha. A malicious attacker might somehow tamper with their binaries. Building from source is the secure way to go. Ok, will do, thanks!

Modified the package to build from source instead of extracting the .deb file.
Attribution: I adapted the working configuration found here.

Verified that core features function correctly.

Thank you all for your time!

I've reduced privileges by using a dedicated nordvpn user. DynamicUser=true behaved inconsistently when I specified the nordvpn group, including when I set it only in SupplementaryGroups=.

Additionally, the nordvpnd source was modified to find helper executables in the <<pkg>>/bin directory (and the PATH, of course). The PATH configured in the systemd unit file now includes only paths to the binaries that are needed.

One more thing, nordvpnd failed to recognize the norduserd process, even though both ran as the same user, which is incorrect behavior. As far as I know, this only affects notifications for VPN server connection/disconnection. I verified basic connect/disconnect operations using OpenVPN and NordLynx protocols.

Thanks again for the review!

Changes:

• rebase onto latest master
• use package changes from nordvpn: init at 4.2.0 (package only) #439308

@drupol @LeSuisse: We have pending reviews/write-requested changes from both of you. Please confirm if these items have now become complete, as I would like to proceed with merging this PR. Thank you.

@different-error , looks like v4.2.0 has released. I tried it locally, and the CLI seems to be working well just the same:

diff --git a/pkgs/nordvpn/package.nix b/pkgs/nordvpn/package.nix
index 0038a2d..b9c68c7 100644
--- a/pkgs/nordvpn/package.nix
+++ b/pkgs/nordvpn/package.nix
@@ -42,13 +42,13 @@ let
 in
 buildGoModule (finalAttrs: {
   pname = "nordvpn";
-  version = "4.0.0";
+  version = "4.2.0";
 
   src = fetchFromGitHub {
     owner = "NordSecurity";
     repo = "nordvpn-linux";
     tag = finalAttrs.version;
-    hash = "sha256-0GgMIFi6qrO7NG94vvWprwWr+8j87M5eH5W/pCtSWqs=";
+    hash = "sha256-9uh/UkOS84tVeW/d6qQ6bYPXzGXEoD21QHzrcMcdj7M=";
   };
 
   nativeBuildInputs = [
@@ -64,7 +64,7 @@ buildGoModule (finalAttrs: {
     libxml2_13
   ];
 
-  vendorHash = "sha256-GREoxjXqb28nabNvvcGjQA1rG4h9e/gINqEPY4++6Oo=";
+  vendorHash = "sha256-eUM69CQjbML8fWRG8H3w6x4M+E51YrXX/UCUFHerQmM=";
 
   modPostBuild = ''
     patch -p0 < ${./gokogiri-xpath-expression.patch}

Perhaps we could also start a separate PR to begin packaging the new GUI that NordVPN open sourced with v4.2.0:

• GUI Build
  • https://github.com/NordSecurity/nordvpn-linux/blob/4.2.0/gui/BUILD.md
  • https://github.com/NordSecurity/nordvpn-linux/blob/4.2.0/.github/workflows/gui_ci.yml
• v4.0.0 vs v4.2.0
  • https://github.com/NordSecurity/nordvpn-linux/compare/919fc28253c3ad802403ea156ea511ab2d131e40..84d6668db19105aa50be23f24cadd62da6eff995

@different-error , looks like v4.2.0 has released. I tried it locally, and the CLI seems to be working well just the same:

Thanks for the hashes.

perhaps we could also start a separate PR to begin packaging the new GUI that NordVPN open sourced with v4.2.0:

Sounds good, I can (eventually..) start a draft PR or two for GUI and meshnet support. Looks like they use flutter and I can't find documentation for buildFlutterApplication but I can try to figure something out!

Looks like they use flutter and I can't find documentation for buildFlutterApplication but I can try to figure something out!

I got building and running fairly easily once I switched to using buildFlutterApplication. See diff from this commit:

• 352e20e

I originally went down the wrabbit hole that is NordVPN's build/packaging pipeline for multi architectures/distros, where they use nfpm, rps, gui/scripts/build_application.sh, then using patchShebangs fixing their build scripts. It was such a rube goldberg setup, and made me really appreciate nixpkgs' approach to macro over the basic source build system like buildFlutterApplication or buildGoModule. About the only thing different I think upstream does is alter some flags for debug-info symbols for release builds, so I'm not sure what the nixpkg stance is on this:

• https://github.com/NordSecurity/nordvpn-linux/blob/84d6668db19105aa50be23f24cadd62da6eff995/gui/scripts/build_application.sh#L39-L43

I think this patch could be made more idiomatic by either spinning out src or gui into separate nix files, so that it's still simple to use override stuff like src attributes. I've seen for some other similar flutter and gui app patterns in nixpkgs:

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-already-reviewed/2617/2601

hey, really looking forward to this being added in the near future... thanks to everyone who has been working on this

What are the blockers/status of this project? Could a minimal viable version be shipped soon?

What are the blockers/status of this project? Could a minimal viable version be shipped soon?

yeah it seems to have found itself lodged in "ready for review" for quite some time now..

in the meantime I intend to update it with latest changes from NordVPN sometime next week. thank you everyone for your patience.

Any insight about why meshnet is not supported? I've been using the package just fine until I got hit with an error while trying to use meshnet and I could not find anything useful on the logs.

Any insight about why meshnet is not supported?

@andersonjoseph , meshnet requires dependencies such as libtelio, related discussion from Jun 13th to 18th above:

• nordvpn: init at 4.3.1 #406725 (comment)
• nordvpn: init at 4.3.1 #406725 (comment)

Just a quick version bump to 4.3.1. Going to work on the Flutter GUI now. Hopefully it turns out not too difficult thanks to the prior effort of @ruffsl

Ok, I think the previous build passed because of some cache weirdness. Strangely when I had tested the binary, it spat out that the binary had used version 4.3.1. Anyway, latest commits use the correct vendor and src hashes for 4.3.1. libxml2 successfully removed in the package.

Attempting to build nordvpn's flutter gui. You can find what I have so far here. It does not build atm, complains with the following error:

[ +154 ms] CMake Error at /nix/store/w9jm660dykns6hzrdhxmqfywnc9ail8g-cmake-4.1.2/share/cmake-4.1/Modules/FindPackageHandleStandardArgs.cmake:227 (message):
[        ]   Could NOT find X11 (missing: X11_X11_INCLUDE_PATH X11_X11_LIB)
[        ] Call Stack (most recent call first):
[        ]   /nix/store/w9jm660dykns6hzrdhxmqfywnc9ail8g-cmake-4.1.2/share/cmake-4.1/Modules/FindPackageHandleStandardArgs.cmake:591 (_FPHSA_FAILURE_MESSAGE)
[        ]   /nix/store/w9jm660dykns6hzrdhxmqfywnc9ail8g-cmake-4.1.2/share/cmake-4.1/Modules/FindX11.cmake:671 (find_package_handle_standard_args)
[        ]   CMakeLists.txt:57 (find_package)

Seems like I need to add xorg somehow (nixos discourse). I intend to try again tomorrow.

I've added flutter gui support to the package and removed the salt. Also to avoid rebuilding the cli twice, I've separated out the package into cli.nix and gui.nix. I had to patch their linux CMakeLists.txt to use pkgconfig to find the correct x11 path.

Tested and verified that both standalone package and module work as intended over openvpn and nordlynx.

I intend to work on incorporating meshnet next which I would start on Dec 26th. Hopefully not too difficult thanks to the prior efforts of @dimkNevidimk!

meshnet progress update:

• libtelio package builds
• tests all pass in a pure nix-shell but seem to break when I run nix-build -A libtelio. Not sure why yet..

https://github.com/different-error/nixpkgs/tree/nordvpn-meshnet

https://github.com/different-error/nixpkgs/tree/nordvpn-meshnet/pkgs/by-name/li/libtelio

update:

• I've added libdrop and modified the nordvpn cli recipe to use the tags "telio" "drop".
• they've patched libdrop-go so I believe we can use Go1.24+

Surprisingly, I don't see "meshnet" in the nordvpn settings.

https://github.com/different-error/nixpkgs/tree/nordvpn-meshnet
https://github.com/different-error/nixpkgs/tree/nordvpn-meshnet/pkgs/by-name/li/libdrop
https://github.com/different-error/nixpkgs/tree/nordvpn-meshnet/pkgs/by-name/no/nordvpn

I've caught the flu. I intend to get back to this when I feel healthy enough to do so.

@different-error,

Sorry for not replying earlier, but I think NordVPN team dropped meshnet support completely:
https://nordvpn.com/blog/meshnet-shutdown/

@different-error,

Sorry for not replying earlier, but I think NordVPN team dropped meshnet support completely:
https://nordvpn.com/blog/meshnet-shutdown/

They changed their mind and decided to keep it.

https://nordvpn.com/blog/meshnet-stays

I could use some help getting meshnet working. Please base your changes around my feature branch nordvpn-meshnet. Ty

I could use some help getting meshnet working. Please base your changes around my feature branch nordvpn-meshnet. Ty

I will take a look when I get home from holiday travel (in a couple of hours) 👌

Update here

TL;DR: I got Meshnet working, but it tries to edit /etc/hosts, which causes permission errors.
I can force it to work by changing the file mode to 0644, but that's a dirty hack.

If anyone knows a clean way to grant write permissions to /etc/hosts, it would be great. Another solution is to send a patch with a --no-ns-hosts flag to the upstream repo so we can disable the write attempts and handle hostnames declaratively.

Some nits. Tested successful connection using the GUI.

While progress with meshnet continues, seeing that including it would cause this PR to increase significantly in size, I think we should PR the current changes without meshnet support and include meshnet in the next PR.

I presently intend to break this PR into smaller, newer ones to facilitate review.